<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
  <head>
    <title>Lecture 2: Buffer Overflows</title>
    <meta name="generator" content="Muse">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    
    <link rel="stylesheet" type="text/css"charset="utf-8" media="all" href="../styles/common.css"  />

    <script src="../scripts/jsMath/easy/load.js"></script>
  </head>

  <body>

    <h1>Lecture 2: Buffer Overflows
      <!-- menu start here -->
      <div class="menu">
        <div class="menuitem">
          <a href="../home/index.html">Home</a>
        </div>
        <div class="menuitem">
          <a href="../courses/index.html">Courses</a>
        </div>
        <div class="menuitem">
          <a href="../projects/index.html">Projects</a>
        </div>
        <div class="menuitem">
          <a href="../complang/index.html">CompLang</a>
        </div>
        <div class="menuitem">
          <a href="../code/index.html">CodeReading</a>
        </div>
        <div class="menuitem">
          <a href="../software/index.html">Software</a>
        </div>
        <div class="menuitem">
          <a href="../lectures/index.html">Lectures</a>
        </div>
      </div>
      <!-- menu ends here -->

    </h1>


    <!-- Page published by Emacs Muse begins here -->

<p>from <a href="http://pdos.csail.mit.edu/6.893/2009/lec/l02-buffer-overflows.txt">http://pdos.csail.mit.edu/6.893/2009/lec/l02-buffer-overflows.txt</a></p>

<h2>Two things going on with buffer overflows</h2>

<ol>
<li>gaining control over execution (program counter)</li>
<li>injecting code into the process</li>
</ol>


<h2>Protection mechanisms that the paper talks about?</h2>

<ul>
<li>avoid bugs, auditing

<ul>
<li>ensuring the lack of bugs is hard</li>
<li>finding these bugs can be easy:
<center>
<p>supply large inputs
watch for a program to crash
look at what the large input corrupted, see if you can exploit it</p>
</center></li>
<li>simple approach finds simple bugs, but not tricky corner cases

<ul>
<li>tools called &quot;<strong>fuzzers</strong>&quot; do this mechanically</li>
<li>we'll look at one of these systems in a later lecture</li>
</ul></li>
</ul></li>

<li>non-executable buffers/stack
<center>
<p>[ paper doesn't mention, but can make all writable memory non-exec ]</p>
</center></li>

<li>bounds checking

<ul>
<li>type-safe languages</li>
<li>why doesn't C have bounds checking?</li>
<li>Compaq C compiler</li>
<li>modify pointer representation</li>
<li><strong>keep shadow data structures (Jones&amp;Kelly)</strong>

<ul>
<li>keeps track of allocated objects in memory</li>
<li>for each pointer expression (in code compiled with their compiler):

<ul>
<li>compute the base address, according to some rules</li>
<li>compute the pointer expression value</li>
<li>check that the pointer falls inside the object for base address</li>
<li>if the pointer is out-of-range, flag an error</li>
</ul></li>
<li>can catch bugs across functions

<ul>
<li>as long as both the alloc site and overflow site are recompiled</li>
</ul></li>
<li>slowdown for pointer-intensive code (30x for matrix multiply)</li>
</ul></li>
<li>whole-stack-frame bounds checking (libsafe, Snarskii, etc):</li>
</ul></li>
</ul>


<h2>Protection mechanisms the paper doesn't mention?</h2>

<ul>
<li>make it difficult to inject code: ASLR, stack randomization

<ul>
<li>weakness: leak/guess addresses

<ul>
<li>function pointers not usually thought of as secret before</li>
<li>32-bit machines: only a few bits of randomness</li>
<li>more effective on a 64-bit machine</li>
</ul></li>
<li>fill address space with shell code

<ul>
<li>many nop's followed by shell code</li>
<li>random jump has some reasonable chance of running your code</li>
</ul></li>
<li>doesn't help with logic overflows</li>
</ul></li>
</ul>

<ul>
<li>randomization has been used to defend against code injection elsewhere

<ul>
<li>syscall # randomization</li>
<li>SQL injection: SQL language randomization</li>
<li>instruction set randomization</li>
</ul>

<ul>
<li>prevent execution dependence on injected data: taint tracking</li>
</ul></li>
<li>what about using injected data as an offset?

<ul>
<li>control flow integrity</li>
</ul></li>
<li>statically analyze possible control flows</li>
<li>dynamically enforce it

<ul>
<li>structure your program so buffer overflows don't matter (priv sep)</li>
</ul></li>
<li>requires programmer effort to re-design application</li>
</ul>



<!-- Page published by Emacs Muse ends here -->
<hl />
<p />
<!-- <center> -->
<!--   Updated at  -->
<!--   2010-02-27 -->
<!-- </center> -->

<script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
  try {
  var pageTracker = _gat._getTracker("UA-2241833-12");
  pageTracker._trackPageview();
  } catch(err) {}</script>

</body>
</html>

